Scroll to navigation

SSSD(8) Сторінки підручника SSSD SSSD(8)

NAME

sssd - Фонова служба безпеки системи

SYNOPSIS

sssd [параметри]

ОПИС

У SSSD передбачено набір фонових служб для керування доступом до віддалених каталогів та механізмами розпізнавання. SSSD надає операційній системі інтерфейси NSS і PAM, а також систему придатних для під’єднання модулів для встановлення з’єднання з декількома різними джерелами даних щодо облікових записів та інтерфейс D-Bus. SSSD також є основою для систем перевірки клієнтських систем та служб обслуговування правил доступу для проєктів, подібних до FreeIPA. SSSD надає стійкішу базу даних для збереження записів локальних користувачів, а також додаткових даних щодо користувачів.

ПАРАМЕТРИ

-d,--debug-level РІВЕНЬ

У SSSD передбачено два представлення для визначення рівня діагностики. Найпростішим є визначення десяткового значення у діапазоні 0-9. Кожному значенню відповідає вмикання відповідного рівня діагностики і усіх нижчих рівнів. Точніше визначення вмикання або вимикання (якщо це потрібно) специфічних рівнів можна встановити за допомогою шістнадцяткової бітової маски.

Будь ласка, зауважте, що кожна служба SSSD веде журнал у власному файлі. Також зауважте, що вмикання “debug_level” у розділі “[sssd]” вмикає діагностику лише для самого процесу sssd, а не для процесів відповідача чи надавача даних. Для отримання діагностичних повідомлень слід додати параметр «debug_level» до усіх розділів, для яких слід створювати журнал діагностичних повідомлень.

Окрім зміни рівня ведення журналу у файлі налаштувань за допомогою параметра «debug_level», який не змінюється під час роботи, але зміна якого потребує перезапуску SSSD, можна змінити режим діагностики без перезапуску за допомогою програми sss_debuglevel(8).

Рівні діагностики, передбачені у поточній версії:

0, 0x0010: критичні помилки з аварійним завершенням роботи. Всі помилки, які не дають SSSD змоги розпочати або продовжувати роботу.

1, 0x0020: критичні помилки. Помилки, які не призводять до аварійного завершення роботи SSSD, але означають, що одна з основних можливостей не працює належним чином.

2, 0x0040: серйозні помилки. Повідомлення про такі помилки означають, що не вдалося виконати певний запит або дію.

3, 0x0080: незначні помилки. Це помилки які можуть призвести до помилок під час виконання дій.

4, 0x0100: параметри налаштування.

5, 0x0200: дані функцій.

6, 0x0400: повідомлення трасування для функцій дій.

7, 0x1000: повідомлення трасування для функцій внутрішнього трасування.

8, 0x2000: вміст внутрішніх змінних функцій, який може бути цікавим.

9, 0x4000: дані трасування найнижчого рівня.

9, 0x20000: швидкодія і статистичні дані; будь ласка, зауважте, що через спосіб, у яких програма обробляє запити на внутрішньому рівні записаний до журналу час виконання запиту може бути довшим за справжній.

10, 0x10000: ще докладніші дані трасування libldb низького рівня. Навряд чи коли знадобляться.

Щоб до журналу було записано дані потрібних бітових масок рівнів діагностики, просто додайте відповідні числа, як це показано у наведених нижче прикладах:

Example: щоб до журналу було записано дані щодо критичних помилок з аварійним завершенням роботи, критичних помилок, серйозних помилок та дані функцій, скористайтеся рівнем діагностики 0x0270.

Приклад: щоб до журналу було записано критичні помилки з аварійним завершенням роботи, параметри налаштування, дані функцій та повідомлення трасування для функцій внутрішнього керування, скористайтеся рівнем 0x1310.

Зауваження: формат бітових масок для рівнів діагностики впроваджено у версії 1.7.0.

Типове значення: 0x0070 (тобто фатальні, критичні та серйозні помилки; відповідає встановленню значення 2 у десятковому записі)

--debug-timestamps=режим

1: додати часову позначку до діагностичних повідомлень.

0: вимкнути часову позначку у діагностичних повідомленнях

Типове значення: 1

--debug-microseconds=режим

1: додати значення мікросекунд до часової позначки у діагностичних повідомленнях

0: вимкнути додавання мікросекунд до часової позначки

Типове значення: 0

--logger=значення

Місце, куди SSSD надсилатиме повідомлення журналу.

stderr: переспрямувати діагностичні повідомлення до стандартного виведення помилок.

files: переспрямувати діагностичні повідомлення до файлів журналу. Типово файли журналів зберігаються у /var/log/sssd, передбачено також окремий журнал для кожної служби і домену SSSD.

journald: переспрямувати діагностичні повідомлення до systemd-journald

Типове значення: не встановлено (резервною буде journald, якщо вона доступна, інакше буде використано stderr)

-D,--daemon

Перейти у режим фонової служби після запуску.

-i,--interactive

Запустити програму у звичайному режимі, не створювати фонової служби.

-c,--config

Визначити нетиповий файл налаштувань. Типовим файлом налаштувань є /etc/sssd/sssd.conf. Довідку щодо синтаксису та параметрів файла налаштувань можна знайти на сторінці довідника (man) sssd.conf(5).

-g,--genconf

Не запускати SSSD, а лише оновити базу даних налаштувань на основі вмісту /etc/sssd/sssd.conf і завершити роботу.

-s,--genconf-section

Подібний до “--genconf”, але наказує програмі освіжити лише окремий розділу на основі файла налаштувань. Цей параметр корисний, в основному, для виклику з файлів модулів systemd з метою дозволити відповідачам, які активуються з сокетів, освіжати налаштування без потреби у перезапуску адміністратором усього SSSD.

-?,--help

Показати довідкове повідомлення і завершити роботу.

--version

Вивести номер версії і завершити роботу.

Сигнали

SIGTERM/SIGINT

Повідомляє SSSD, що слід поступово завершити роботу всіх дочірніх процесів, а потім завершити роботу монітора.

SIGHUP

Повідомляє SSSD, що слід припинити запис до файлів діагностичних даних з поточними дескрипторами, закрити і повторно відкрити ці файли. Цей сигнал призначено для полегшення процедури архівування журналів за допомогою програм, подібних до logrotate.

SIGUSR1

Наказує SSSD імітувати автономну дію, тривалість якої визначається параметром «offline_timeout». Найкориснішим застосуванням є тестування служби. Сигнал може бути надіслано або процесу sssd, або процесу sssd_be безпосередньо.

SIGUSR2

Наказує SSSD перейти у режим роботи у мережі негайно. Найкориснішим застосуванням є тестування служби. Сигнал може бути надіслано або процесу sssd, або процесу sssd_be безпосередньо.

ЗАУВАЖЕННЯ

Якщо для змінної середовища SSS_NSS_USE_MEMCACHE встановлено значення «NO», клієнтські програми не використовуватимуть fast у кеші у пам’яті.

ТАКОЖ ПЕРЕГЛЯНЬТЕ

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-files(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)

AUTHORS

Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/

05/24/2024 SSSD